Computer systems generally have hardware and software mechanisms which are used in combination to detect and appropriately respond to conditions which arise during the execution of programs. The terms condition and exception are often used interchangeably. These conditions or exceptions may be errors such as using an invalid machine address or attempting to divide by zero. Conditions also include events which may not be actual errors, but which require special attention. Examples of this type of condition might include an attempt to reference an uninitialized variable. Hardware detected conditions generally cause the CPU to stop executing the program which caused the condition through a hardware interrupt mechanism. The low level software or firmware interrupt handlers in the system will initially be given control. Control may then be passed up through the various layers of programs currently executing such as an operating system, a run-time environment program, and an application program through software branching and calling techniques. Software detected conditions generally result in the calling of routines which have been designated as condition handlers. When a program causes a condition handler to be executed, the program is said to signal a condition.
A condition is defined as any synchronous event that may need to be brought to the attention of an executing program or of language routines supporting that program. Conditions may originate from an of the following:
Hardware-detected errors (known as program interruptions in IBM System/370 terminology) are signalled by the central processing unit. The condition codes are derived from those defined for the machine on which the program is executing. PA1 Operating system and subsystem detected errors (exceptions) are software errors, which are reported to the user as ABENDs on IBM'S MVS and VM operating systems. PA1 A software-generated signal is a condition which is intentionally and explicitly created by an application program. The condition may be unique to the application or may be used to simulate one of the other classes of conditions. The signal may be communicated (generated and received) within the same language or between different languages. Software-generated signals are handled in the same manner as conditions detected by the hardware or operating system. Operating systems, language library routines, application programs, and subordinate condition handlers may produce software-generated signals. PA1 a linkable set of condition handling routines which are accessible to the user regardless of what source language is being used; PA1 a mechanism for altering the type of condition being processed without invoking the entire condition handling mechanism from the beginning for the new condition; PA1 a method or means for separating condition handling from routine termination of a procedure upon completion; PA1 a method or means for providing a controlled mechanism for changing the point at which execution of the code can resume after a condition has been successfully handled.
Some of the system's condition handlers may always be the same while others may change dynamically according to what type of operating system routine or application program is running at the time. It is common for high level languages (HLL) compilers, such as FORTRAN, PL/I, etc., to provide what is called a run-time environment (RTE) for application programs written in their HLL. The RTE may provide routines which interface with the operating system to capture control when certain conditions occur and may allow the application program to setup user routines to which control will be transferred for certain conditions. The distinction between functions provided by an operating system and by an RTE is largely arbitrary. An operating system could provide all of the same functions as an RTE and thereby obviate the need for a separate RTE.
The following terms are used in this specification:
CEECIB
A variable where certain global status information is stored.
Condition Severity Codes
will be used ranging from 0 to 4 with 0 being the least severe.
Condition Manager
is any program or means which gains control of the computer system when a condition occurs and which manages the handling of that condition by executing various system and/or user application routines. It may be part of the operating system, run-time environment or an application program.
Cursor
is an address pointer that points to an executable instruction.
Debugger
is a program which is used to execute an application program under test conditions so that errors may be found.
Handle Cursor
is the cursor that indicates both the handling routine and the stack frame for which the handler is invoked.
Enablement
is the capability to intercept a condition before presentation to any other condition handler, and to determine whether the condition should be ignored or not. Unrecognized conditions are always defined to be enabled. Normally, enablement is used to supplement the hardware for capabilities that it does not have and for language enforcement of the language's semantics. An example of supplementing the hardware is the specialized handling of floating-point overflow exceptions based on language specifications (on some machines this can be achieved through masking the exception).
Enclave
is a collection of a main routine and zero or more subroutines. The main routine is executed first. Threads originate in enclaves.
INT2 and INT4
will be used as part of C syntax interface definitions to mean two byte and four byte integers respectively.
Platform
is the combination of an operating system and computer hardware on which programs may execute.
Resume Cursor
is the cursor designating the point in the application where execution can be restarted.
Resume
is the termination of condition handling, and the transfer of control to the instruction and stack frame denoted by the Resume Cursor.
Safe Condition
is any condition which may be ignored if they are not handled.
Stack Frame
is the set registers and condition flags which are pushed onto the computer's stack when an interrupt occurs or registers are saved for a call or branch.
Stack Frame Zero
is the conceptual stack frame immediately prior to the stack frame for the first routine. It is the theoretical place where the thread or task is initialized, the first procedure is called from and termination is initiated from. For the purposes of condition handling, the zeroth stack frame is the frame at which the default actions for a language are applied.
Thread
is the term for the basic line of execution in a routine.
The immediate function of any condition handling mechanism in a system is to diagnose errors, and then selectively report and/or tolerate them, possibly after restoring some data values. These actions are taken to solve specific problems within the system and to permit the system to meet its objectives. Historically, condition processing in High-Level Languages was implemented as appropriate for the objectives of each individual programming language. Not surprisingly, these individual implementations are different from each other, and in fact are often mutually destructive when used together in the same application.
In the prior art condition handling is performed based on the source language of the program being executed. Thus, a program generated using a COBOL compiler will use one set of condition handling routines while programs written in PL/I use a different set. Given the desirability and need to support an arbitrary mix of High-Level Languages in an application, it is essential to develop a condition handling model that manages this mixed environment as well as the single-language environment. A basic requirement is to meet the standard for each individual language. Any application implemented entirely within one language must operate as specified in that language's external standard. Without this, a condition handling model is not viable at all.
Next, it is important to provide behavior for a mixed-language application that is rational, understandable, and predictable. In effect, this defines a new "standard" for mixed-language applications. Currently, there is no recognized standard for these environments. The need is to support such applications with a consistent condition handling model no matter what the language combinations may be. At the same time, the condition handling model must not prevent the languages from meeting their standards as far as possible in mixed-language situations.
Programmer-specified condition handlers should be able to get control for all "recoverable" conditions (other than those conditions which are indicated via some sort of return code mechanism instead) regardless of what source language is being used to write the program. It should be possible for a programmer to design a "subroutine" so that it is insulated from the condition handling characteristics of its caller. This subroutine may consist of many subroutines and/or functions used together as a unit. It should be possible for a programmer to use a well-designed subroutine without the need to be concerned about its internal condition handling mechanisms or the applications that may be contained therein. It should be possible for one well-designed subroutine to be substituted for an equivalent one written in a different language without causing any differences (including but not limited to condition handling) visible to the caller. This does not mean that language semantics will be changed in any way. The programmer must have at his disposal mechanisms which are reasonably independent of any global condition handling scheme which a particular language may implement. A single-language application which uses only the language-defined interfaces for condition handling should behave according to the language specification, including any global condition handling effects.
One aspect of predictability that needs to be explicitly stated is where execution can resume after a condition is successfully handled (i.e., "tolerated"). When condition handling is used to accomplish backout and state restoration, the ability of a condition handler to force execution to resume at an arbitrary location in an arbitrary subroutine can be extremely dangerous. This is because one condition handler may perform backout operations (including, for example, releasing locks) on the assumption that the procedure that incurred the condition will not continue executing. If a later condition handler then decides to resume at the point of the condition, results are unpredictable at best. Thus, once a condition handler has determined that a particular invocation (level of call) cannot continue normal execution, it must be possible to perform backout for that invocation without a danger that a later condition handler may reverse the decision and resume execution in the invocation.
All HLL condition handlers should be prepared to diagnose the condition if they are the condition handler for the stack frame in which the condition occurred. The further one gets from this stack frame, the less information is available to do that diagnosis. If the resume cursor is moved past this stack frame, all information is lost. Therefore, all diagnosis must be done before any condition handling or condition toleration is begun.
Currently existing HLL compilers provide a varying degree of user access to condition handling mechanisms. The PL/I language has a relatively powerful set of ways that a user can tap into the condition handling process through the use of "ON-condition". The COBOL language on the other hand has virtually no mechanism to allow the user to get control when conditions occur. There are a large number of computer programming languages available today. It would be a cumbersome solution to require that the language syntax of these compilers be modified in any major way to provide for built-in user access to condition handling.
Current implementations of language specific condition handling provide for the existence of handlers which can be passed a parameter which determines whether the handler will actually handle the condition or simply report on whether the condition is enabled.
What is needed and not provided in the prior art is a general mechanism for condition handling which can function in a multi-language environment and satisfy the needs outlined above. Specifically the prior art does not provide: